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Abstract 

Proposals  for  programmable  network  infras¬ 
tructures,  such  as  active  networks  and  open  sig¬ 
naling,  provide  programmers  with  access  to 
network  resources  and  data  structures.  The  moti¬ 
vation  for  providing  these  interfaces  is  accelerated 
introduction  of  new  services,  but  exposure  of  the 
interfaces  introduces  many  new  security  risks.  The 
risks  can  be  reduced  or  eliminated  via  appropri¬ 
ate  restrictions  on  the  exported  interfaces.  I  n  this 
article  we  describe  some  of  the  security  issues 
raised  by  active  networks.  We  then  describe  our 
secure  active  network  environment  architecture. 
SA  N  E  was  designed  as  a  security  infrastructure 
for  active  networks,  and  was  implemented  in  the 
SwitchW  are  architecture.  SA  N  E  restricts  the 
actions  loaded  modules  (including  "capsules") 
can  perform  by  restricting  the  resources  that  can 
be  named;  this  is  further  extended  to  remote 
invocation  by  means  of  cryptographic  credentials. 
SANE  can  be  extended  to  support  restricted  con¬ 
trol  of  quality  of  service  in  a  programmable  net¬ 
work  element.  The  Piglet  lightweight  device 
kernel  provides  a  "Virtual  Clock"  type  of  schedul¬ 
ing  discipline  for  network  traffic,  and  exports  sev¬ 
eral  tuning  knobs  with  which  the  clock  can  be 
adjusted.  The  ALIEN  active  loader  provides  safe 
access  to  these  knobs  to  modules  that  operate  on 
the  network  element.  Thus,  the  proposed  SQoSH 
architecture  is  able  to  provide  safe,  secure  access 
to  network  resources,  while  allowing  these 
resources  to  be  managed  by  end  users  needing 
customized  networking  services.  A  desirable  con¬ 
sequence  of  SQoSH 's  integration  of  access  con¬ 
trol  and  resource  control  is  that  a  large  class  of 
denial-of-service  attacks,  unaddressed  solely  with 
access  control  and  cryptographic  protocols,  can 
now  be  prevented. 

Introduction 

This  article  describes  one  approach  to  providing 
quality  of  service  (QoS)  guarantees  in  a  network 
using  a  secure  active  network  infrastructure 
(Secure  A  ctive  N  etwork  E  nvironment,  SA  N  E ) 
and  a  novel  low-overhead  multiprocessor  operat¬ 
ing  system  (Piglet).  We  begin  by  discussing  the 
notion  of  security,  provide  a  constructive  defini¬ 
tion  useful  for  asserting  general  security  proper¬ 
ties,  and  discuss  the  mapping  of  this  definition 


onto  computer  networks,  and  outline  the  chal¬ 
lenges  of  securing  programmable  network  infras¬ 
tructures,  which  the  remainder  of  the  article 
addresses. 

Security 

It  is  attractive  to  think  of  security  as  a  clearcut 
property  of  a  system,  as  in  the  definition  of  odd 
and  even  numbers.  U  nfortunately,  security  is  not 
as  easily  abstracted,  since  it  is  fundamentally  a 
context-dependent  property  of  an  engineered  sys¬ 
tem.  F or  example,  some  applications  can  tolerate 
near-infinite  delays,  while  others  have  strict  real¬ 
time  requirements.  Thus,  a  system  design  which 
guarantees  reliable  and  eventual  action  may  be 
considered  secure  in  the  first  case  but  inadequate 
(e.g.,  against  "denial-of-service"  or  DoS  attacks) 
in  the  latter  (e.g.,  a  military  command  and  con¬ 
trol  system  susceptible  to  DoS  attacks). 

I  n  general,  a  secure  system  is  one  that  meets 
or  exceeds  an  application-specified  set  of  security 
policy  requirements.  So,  for  example,  in  message 
delivery,  the  high-level  requirements  may  be  that 
the  correct  information  gets  to  the  right  person, 
in  the  right  place,  at  the  right  time.  The  details  of 
"right"  are  determined  by  the  application's  needs; 
for  example,  timely  message  delivery  is  crucial 
for  battlefield  or  stock-trading  tasks. 

Security  for  Active  Networks 

Active  networks  are  proposed  for  packet-switched 
networks  which  are  programmable,  perhaps  on  a 
per-user  or  even  per-packet  basis.  The  more 
aggressive  proposals  share  the  property  that 
"programs"  are  loaded  into  network  elements  on 
the  fly,  providing  rapid  dynamic  reconfiguration 
of  the  network  infrastructure. 

Security  for  active  networking  is  a  major  chal¬ 
lenge,  as  well  as  a  widespread  and  legitimate 
cause  for  concern.  0  ne  view  of  information  secu¬ 
rity  can  be  characterized  as  getting  the  right 
information  to  the  right  person  at  the  right  place 
and  time.  This  is  the  positive  statement  of  a  secu¬ 
rity  policy;  other  security  policies  might  assert 
what  cannot  occur.  The  flexibility  of  an  active 
networking  infrastructure  has  the  potential  effect 
of  hugely  expanding  the  threat  model  for  attacks 
on  the  network  infrastructure.  For  example,  DoS 
attacks  can  now  be  made  against  a  variety  of 
resources,  such  as  CPU  cycles,  output  link  band¬ 
width,  and  storage,  since  these  are  exposed  either 
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wholly  or  in  part  to  loaded  programs. 

T ypical  reasons  to  defer  consideration  of 
security,  aside  from  simple  difficulty,  are  the 
negative  consequences  of  making  a  system  more 
secure  on  flexibility,  usability,  and  performance. 
Since  programming-language-based  approaches 
to  active  networking  offer  advantages  in  terms  of 
flexibility  and  usability,  and  performance  opti¬ 
mizations  for  these  environments  are  ongoing, 
providing  security  to  such  an  environment  would 
offer  an  attractive  design  point  among  the  vari¬ 
ous  trade-offs. 

The  Threat  Model  for 
QoS  Provision  in  an  Active  Network 

A  n  active  network  infrastructure  is  very  different 
from  the  current  I  nternet.  I  n  the  latter,  the  only 
resource  consumed  by  a  packet  at  a  router  is  the 
memory  needed  to  temporarily  store  it  and  the 
CPU  cycles  necessary  to  find  the  correct  route. 
This  overhead  is  generally  quite  small  compared 
to  the  cost  of  executing  an  active  packet,  and 
thus  strict  resource  control  in  the  routers  was 
considered  noncritical,  While  this  approach  has 
worked  well,  it  is  fairly  easy  to  mount  D  oS 
attacks  due  to  the  simple  resource  model. 
Attacks  to  the  infrastructure  itself  are  possible, 
and  result  in  major  network  connectivity  loss. 
Finally,  it  is  very  hard  to  provide  enforceable 
QoS  guarantees. 

I  n  the  context  of  Q  oS,  a  secure  system  is  one 
that  is  secure  against  two  types  of  threats,  which 
we  denote  admission  failures  and  policing  failures. 

A  n  admission  violation  is  one  where  an  unau¬ 
thorized  reallocation  of  bandwidth/resources 
occurs.  For  example,  a  Resource  Reservation 
Protocol  (RSVP)-capable  router  might  be  asked 
to  reallocate  bandwidth  away  from  one  flow  to 
one  that  has  not  paid  for/has  no  right  to  the 
bandwidth.  The  policing  mechanism  is  working 
correctly;  it  is  applying  a  QoS  specification  admit¬ 
ted  by  the  network  infrastructure.  U  nfortunately, 
the  specification  was  unauthorized.  This  is  as 
much  a  threat  in  RSV  P  or  other  resource  reser¬ 
vation  systems  as  it  is  in  an  active  network;  the 
greater  concern  in  the  active  network  is  a  direct 
consequence  of  the  more  complex  resource 
model.  Thus,  an  active  infrastructure  must  be 
able  to  correctly  identify  and  authorize  users  (or, 
more  generally,  principals  in  the  system).  The 
SANE  architecture  provides  such  services  [1], 

A  policing  violation  is  one  where  the  specified 
Q  oS  is  correct,  but  the  system  fails  to  deliver 
what  is  requested.  F  or  example,  a  network  ele¬ 
ment  incorporating  a  computer  might  be  subject 
to  DoS  attacks  based  on  "receive  livelock,"  or 
may  experience  "QoS  crosstalk."  A  second  exam¬ 
ple  is  aggressive  use  of  bandwidth  on  a  shared 
output  port,  which  denies  bandwidth  to  a  process 
with  QoS  requirements.  This  is  a  threat  to  basic 
I P  routers  with  FIFO  queuing  disciplines.  Piglet 
[2],  briefly  described  later,  provides  the  necessary 
mechanism  to  enforce  QoS  policing. 

SQoSH  Applications 

The  proposed  Secure  QoS  Handling  (SQoSH) 
architecture  provides  a  powerful  new  tool  for 
managing  resources  in  a  network.  It  controls 
access  to  managed  resources,  and  integrates  this 


control  with  the  resource  management  mecha¬ 
nisms  provided  by  the  Piglet  operating  system. 
W hile  the  SA N  E/Piglet  combination  represents 
the  first  instance  of  the  SQoSFI  architecture,  we 
believe  that  compelling  applications  will  moti¬ 
vate  deployment  of  SQoSFI  and  SQoSFI  -inspired 
architectures.  Examples  include: 

•  E  conomic  algorithms  for  robust  adaptive 
control:  A ctive  Q oS  is  well  adapted  to  this 
environment  for  two  reasons.  F  irst,  it  is 
critical  that  resources  sold  match  those 
delivered  if  the  marketplace  is  to  work.  Sec¬ 
ond,  the  recovery  strategies  for  flows  that 
are  outbid  in  an  auction  may  be  quite  com¬ 
plex  (e.g.,  aggregating  several  flows,  each  of 
which  delivers  a  portion  of  the  request, 
searching  for  a  different  route,  delaying 
until  the  resources  required  become  avail¬ 
able  at  the  desired  prices,  or  combinations 
of  different  strategies).  We  expect  that  cap¬ 
turing  these  complex  decisions  can  be  done 
most  easily  by  active  packets  in  a  pro¬ 
grammable  infrastructure. 

•  M  ilitary  applications,  where  hierarchical 
command  responsibility  maps  to  multiple 
classes  of  service  and  security:  T  he  SQ  oSH 
architecture  ensures  that  control  requests 
are  authenticated,  autonomous  network  ele¬ 
ments  bootstrap  into  a  secure  state,  and 
(once  admission  requests  are  validated)  ser¬ 
vice  will  be  delivered.  For  example,  a  com¬ 
mand  channel  of  2  percent  of  bandwidth 
could  be  preserved  at  all  times.  For  commer¬ 
cial  applications  this  might  be  considered 
wasteful,  while  military  uses  might  dictate 
provision  of  such  a  no-delay  override  facility. 

The  SQoSH  Architecture 

The  goal  of  SQoSFI  is  to  protect  against  two  types 
of  threats  to  Q  oS  provision,  admission  and  polic¬ 
ing,  Balancing  performance,  flexibility,  and  securi¬ 
ty  considerations  suggests  that  we  make  common 
operations  (e.g.,  those  used  to  classify  packets) 
cheap,  and  make  less  common  operations  more 
expensive  if  this  contributes  to  reducing  the  cost 
of  common  operations.  An  example  of  this 
approach  is  to  provide  heavyweight  authentica¬ 
tion  mechanisms  at  the  level  of  aggregates  of 
packets  such  as  channels  or  flows  so  that  these 
checks  need  not  be  done  on  individual  packets. 

This  suggests  an  architecture  where  authenti¬ 
cation  and  other  resource  management  decisions 
are  "front-loaded"  to  reduce  the  cost  of  subse¬ 
quent  decisions.  W  e  view  this  scheme  as  one 
where  expensive  static  checks  are  traded  for 
cheaper  dynamic  checks.  Thus,  the  SQoSFI  archi¬ 
tecture  echoes  similar  design  decisions  made  in 
restricting  programmability  to  the  control  plane 
and  similar,  although  not  equivalent,  decisions 
made  in  the  overall  SwitchWare  architecture. 

This  division  of  functions  into  admission/ 
authentication  and  policing/provision  isthe 
approach  we  have  chosen  for  SQoSFI .  Figure  1 
illustrates  the  SQ  o S H  architecture  at  a  high 
level.  T he  SA  N  E  system  is  the  only  means  of 
access  to  resource  management  interfaces  pro¬ 
vided  by  Piglet.  FI  eavyweight  cryptographic  oper¬ 
ations  required  for  granting  access  to  Piglet 
resources  are  performed  by  SA  N  E  as  a  front- 
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■  Figure  1.  TheSQoSH  architecture. 


end.  Piglet  is  thus  assured  that  any  resource 
requests  have  been  authenticated,  and  thus 
needs  to  focus  on  whether  the  resources  can  be 
allocated  to  the  validated  request.  Packets  des¬ 
tined  for  SA  N  E  are  demultiplexed  by  Piglet, 
which  provides  basic  packet  delivery  operations 
for  SA  N E  .  The  active  environment  provided  by 
ALIEN  allows  for  considerable  flexibility  in  arbi¬ 
trating  and  managing  the  protected  resources. 

Since  Piglet  is  intended  as  an  asymmetric 
multiprocessor  operating  system,  multiple 
instances  of  Piglet  can  manage  multiple  network 
line  cards.  A  full-scale  SQ oSH  system  would 
consist  of  a  multiprocessor  with  a  Piglet  instance 
on  each  device-managing  processor  (a  resizable 
subset  of  all  the  processors  in  the  system).  I  n 
this  way,  all  device  I/O  can  be  managed  by  Piglet. 
Since  a  typical  model  for  scheduling  resources  is 
activity  triggered  by  a  device  interrupt,  Piglet  can 
manage  interrupts,  buffering,  status  polling,  and 
so  on,  and  protect  the  host  operating  system 
from  device-initiated  actions. 


Security  and  Safety  in 
SwitchWare 

While  the  SQoSH  architecture  is  portable  across 
many  active  networking  environments,  our  exper¬ 
imental  prototype  is  constructed  in  the  context 
of  the  SwitchW are  architecture.  SwitchW are  is 
based  on  the  approach  of  using  restricted  seman¬ 
tics  to  contain  the  behavior  of  potentially  mis¬ 
chievous  programs.  Thishasthe  benefit  that 
enforcing  restrictions  can  be  performed  once  at 
compile  or  link  time,  resulting  in  lower  cost  than 
an  OS  approach  such  as  memory  protection, 
which  requires  repeated  checks  at  runtime. 
These  semantic  restrictions  depend  on  the 
integrity  of  other  system  components  such  as  the 
operating  system  and  shared  libraries.  The 
semantic  restrictions  are  enforced  with  a  strongly 
typed  language  which  supports  garbage  collec¬ 
tion  and  module  thinning. 

The  SwitchW  are  project  is  a  joint  effort  of 
the  U  niversity  of  Pennsylvania  and  Bellcore 


(now  Telcordia).  The  overall  project  goal  isto 
accelerate  network  evolution  by  turning  store- 
and-forward  networks  into  store-COM PUTE - 
and-forward  networks,  an  approach  we 
originated  in  the  Protocol  Boosters  [3],  The  goal 
is  to  build  a  network  infrastructure  which  bal¬ 
ances  flexibility,  usability,  security,  and  perfor¬ 
mance.  The  current  infrastructure  provides  a 
model  where  modules  can  be  loaded  into  the 
node  on  the  fly  by  the  A  L I E  N  active  loader  [4], 

T  he  basis  of  the  A  L I E  N  approach  is  restrict- 
ing  a  general  mode  of  computation.  Caml  pro¬ 
vides  the  general  model,  and  ALIEN  provides 
the  restrictions.  The  loader  is  sufficiently  power¬ 
ful  that  the  extreme  case  of  "capsules"  can  be 
supported  by  treating  each  packet  as  a  module, 
although  a  more  typical  use  of  the  facility  is  to 
add  a  service  used  by  streams  of  inactive  packets. 

M  ore  precisely,  Caml  provides  a  model  of 
computation  equivalent  to  that  of  a  T uring 
machine,  By  itself,  this  computation  model  is 
secure  since  it  involves  no  shared  resources.  I  n 
practice,  since  we  are  running  on  a  real  machine, 
we  have  DoS  attacks  that  arise  because  our  CPU 
and  memory  resources  are  finite.  Additionally, 
the  actual  Caml  environment  also  includes  a  run¬ 
time  system  that,  among  other  features,  provides 
access  to  operating  system  primitives,  which,  in 
turn,  provide  access  to  shared  resources.  Further¬ 
more,  under  this  runtime,  memory  is  a  shared 
resource.  The  role  of  ALIEN  is  to  control  the 
access  to  these  shared  resources  and  thereby 
ensure  that  a  loaded  program  (called  a  switchiet) 
does  not  exceed  its  resource  limits  (ALIEN  is  not 
responsible  for  determining  those  limits). 


The  Secure  Active  Network 
Environment 

A  n  illustration  of  SA  N  E  in  the  context  of  the 
overall  SwitchWare  network  element  architec¬ 
ture  is  shown  in  Fig.  2. 

SANE  buildson  ALIEN  in  order  to  provide 
security  services  for  an  active  network.  These 
services  include: 

•  Secure  bootstrapping  and  component  recov¬ 
ery  using  the  A  E  G I S  architecture  [5], 

•  Cryptographic  primitives  provided  as 
ALIEN  libraries. 

•  Packet  encryption  and  authentication,  for 
both  data  packets  and  active  capsules. 

•  A  key  establishment  protocol  (KE  P),  which 
allows  nodes  or  users  to  establish  secret 
keys  and  exchange  certificates.  This  proto¬ 
col  is  used  for: 

-Secure  bootstrap  component  recovery  in 
AEGIS  [6] 

-Session-key  establishment  and  principal 
authentication  and  authorization.  The  prin¬ 
cipals  can  authenticate  each  other  and 
exchange  authorization  credentials.  We 
make  use  of  K eyN  ote  [7]  credentials  to 
specify  the  resource  usage  and  access  con¬ 
trol  policies  ALIEN  enforces. 

-Secure  neighbor  discovery  once  the  node 
boots.  The  node  may  also  establish  trust 
relationships  with  its  neighbors;  these  may 
then  be  used  by  mobile-agent  types  of  appli¬ 
cations,  or  to  secure  other  critical  infra- 


4 


IEEE  Communications  M  agazine  •  A  pril  2000 


structure  information  (e.g.,  routing  updates). 

•  Administrative  domains  allow  a  set  of  net¬ 
work  elements  under  the  same  administra¬ 
tive  control  to  restrict  security  requirements 
when  communicating  with  each  other.  Bor¬ 
der  elements  act  as  present-day  firewalls 
and  may  require  extensive  authentication 
before  allowing  access  to  the  internal  net¬ 
work.  Furthermore,  they  can  impose  restric¬ 
tions  on  active  packets  by  encapsulating 
them  in  active  "wrappers." 

•  Naming  services  allow  for  secure  module 
identification. 

SANE  Summary 

The  SA  N  E  elements  are  combined  into  a  system 
using  the  following  design  principles: 

•  Dynamic  checks,  performed  while  the  active 
node  is  operating,  should  be  as  fast  as  pos¬ 
sible,  since  they  are  done  many  times. 

•  Static  checks,  performed  before  the  active 
node  enters  the  operating  state,  can  be 
expensive,  since  they  are  done  infrequently 
(typically  once). 

•  System  performance  can  be  improved  by 
trade-offs  that  decrease  the  cost  of  the 
dynamic  checks  at  the  expense  of  more 
costly  static  checks,  or,  ideally,  by  using 
static  checks  to  eliminate  the  need  for  any 
dynamic  checking  at  all,  analogous  to  "once 
at  compile  time"  versus  "many  at  runtime." 

Resource  Control 

Resource  control  on  the  active  switch  is  imposed 
by  the  runtime  system,  as  specified  by  the  cre¬ 
dentials  exchanged  during  key  establishment. 
Piglet  controls  resource  usage  based  on  the  cre¬ 
dentials  acquired  bySANE.The  protected 
resources  include  access  to  standard  and  loaded 
modules,  CPU  cycles,  memory  allocated,  number 
of  packets,  latency  and  bandwidth  requirements, 
and  so  on.  F or  the  Piglet  experiments  we  report 
later  that  we  have  limited  resource  management 
to  network  bandwidth.  There  is  a  great  deal  of 
further  research  necessary  to  determine  which 
are  the  right  resources  to  manage  and  how  to 
resolve  conflicting  resource  requests. 

Since  a  tenet  of  our  approach  is  controlled 
module  loading,  SA  N  E  must  manage  loading 
modules  in  a  secure  fashion  if  it  is  to  be  useful 
in  an  active  network.  It  must  control  which  mod¬ 
ules  are  loaded,  and  by  whom.  SA  N  E  associates 
cryptographic  credentials  with  modules.  SA  N  E 
can  either  require  a  certificate  for  loading  a  par¬ 
ticular  module,  or  allow  universal  loading  of  the 
module.  Examples  where  such  universal  loading 
may  be  useful  include  low-cost  operations  like 
ping,  as  well  as  the  security  operations  used  for 
bootstrapping  the  security  relationship  with 
remote  switches.  There  are  two  classes  of  certifi¬ 
cates  that  can  be  presented  by  a  user  packet 
requesting  access  to  a  resource  via  a  module.  A  n 
administrative  certificate  allows  loading  of  any  or 
all  modules  into  the  system;  it  is  intended  for 
management  and  emergencies  as  might  arise, 
and  can  be  thought  of  as  analogous  to  a  "master 
key"  granted  by  the  switch  administrator.  M  ore 
commonly,  certificates  are  used  to  permit  load¬ 
ing  of  selected  modules.  F  or  system  resources 
(e.g.,  memory  or  bandwidth),  the  certificates  can 
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Figure  2.  SANE's  relation  to  SwitchWare. 


also  specify  the  allowed  usage  patterns  (e.g.,  "no 
more  than  4  M  b/s" ) .  Asa  result,  this  scheme 
allows  fine-grained  control  of  switch  resources. 

Piglet 

W  hile  the  SA  N  E  architecture  presents  a  secure 
resource  management  interface  to  switchlets,  the 
underlying  system  must  be  capable  of  providing 
the  appropriate  capabilities  to  implement  that 
interface.  In  theSQoSFI  architecture  those  capa¬ 
bilities  are  provided  by  Piglet  [8],  a  multiproces¬ 
sor  operating  system  designed  to  provide 
applications  with  low  overhead  direct  access  to 
network  resources. 

Piglet:  Structure  and  Architecture 

The  Piglet  architecture  is  based  around  the  con¬ 
cept  of  an  active  kernel  —  one  or  more  system 
C  PU  s  are  dedicated  to  continually  running  the 
lightweight  device  kernel  (LDK).TheLDK  con¬ 
sists  of  only  those  parts  of  the  operating  system 
that  directly  interact  with  physical  devices;  like 
other  vertically  structured  operating  systems,  it 
implements  only  the  minimal  set  of  functions 
necessary  to  support  direct  user-level  access  to 
those  devices,  namely  protection,  translation, 
and  multiplexing. 

This  has  two  primary  benefits:  first,  since  it 
runs  continuously  the  L  D  K  communicates  with 
devices  by  polling,  rather  than  using  interrupts, 
thus  eliminating  the  possibility  of  interrupt- 
based  livelock,  potentially  reducing  kernel 
response  time  and  greatly  simplifying  the  kernel 
implementation;  second,  applications  invoke  ker¬ 
nel  services  using  shared  memory  communica¬ 
tion,  a  much  lower-overhead  mechanism  than 
the  conventional  system-call  trap.  We  believe 
that  in  systems  where  I/O  makes  up  a  large  frac¬ 
tion  of  the  workload,  such  as  an  active  network 
element,  these  two  benefits  combined  more  than 
compensate  for  the  cost  of  dedicating  one  pro¬ 
cessor  to  running  the  LDK. 

Reducing  System-Call  Overhead  —  To  evalu¬ 
ate  how  successfully  Piglet  manages  to  reduce 
the  invocation  overhead  for  system  services,  we 
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frameset_t  * 

piglet_create_frameset  (int  tx_bufs, 

int  rx_bufs, 
unsigned  options) ; 

int 

piglet_set_filter  (frameset_t  *flow, 

filter_t  *filter) ; 

int 

piglet_set_vclock  (frameset_t  *flow, 

unsigned  period, 
unsigned  limit) ; 

■  Figure  3.  Flow  management  functions  in  Piglet. 


Payload  (bytes) 

Modal  RTT(ps) 

Linux  Piglet 

64 

199 

161 

256 

253 

215 

1024 

468 

413 

■  Table  1.  M  octal  ping  round-trip  times. 


performed  a  simple  experiment.  The  standard 
ping  program  was  modified  to  use  the  Piglet 
shared-memory  interface  to  send  echo  packets. 
W e  then  measured  the  round-trip  time  for  vari¬ 
ous  sizes  of  packet,  and  compared  these  to  the 
times  measured  for  the  unmodified  program  in 
the  same  test  environment.  Since  the  only  differ¬ 
ence  between  the  two  tests  was  the  mechanism 
used  to  send  packets,  any  differences  in  round- 
trip  time  can  be  attributed  to  the  overhead  of 
those  mechanisms. 

Table  1  shows  the  modal  round-trip  time 
measured  for  various  sizes  of  packets;  a  more 
detailed  histogram  and  analysis  of  these  results 
is  presented  in  [8], 

These  figures  show  that  the  difference  in 
round-trip  time,  or  equivalently  the  difference  in 
the  overhead  of  sending  a  packet,  varies  from  38 
p.s  to  55  ps,  there  being  some  dependence  on 
payload  size  due  to  Piglet  performing  less  data 
copying  than  Linux.  We  believe  that  such  a 
reduction,  due  to  the  Piglet  architecture,  could 
be  significant  in  a  system  such  as  a  SQoSH  node, 
where  a  large  proportion  of  the  workload  is  in 
I/O  operations. 

Resource  Management  in  Piglet 

Piglet's  network  resource  management  functions 
are  based  on  an  abstract  data  structure  known  as  a 
frameset.  A  frameset  consists  of  independent 
transmit  and  receive  queues  into  which  frames, 
each  corresponding  to  a  network  packet,  can  be 
placed.  Services  can  be  associated  with  framesets 
in  order  to  manipulate  and  process  frames  — 
since  services  form  an  integral  part  of  the  Piglet 
OS,  they  have  full  access  to  the  host  system  and 
1  Here  and  in  our  expert-  can  thus  perform  almost  any  conceivable  function. 

mental  results  we  use  the  For  the  purposes  of  network  element  applica- 

convention  thatlMb/s=  tions  each  frameset  is  logically  associated  with  a 
(TO6/  b/s.  network  flow.  The  exact  details  of  a  flow  specifi¬ 


cation  are  bound  only  by  the  packet-filtering 
mechanism  employed  by  Piglet  to  classify 
received  network  packets  into  flows  (and  hence 
demultiplex  to  the  appropriate  frameset).  A  flow 
can  be  defined  as  broadly  as  "all  packets  received 
on  this  network  interface"  or  as  specifically  as 
"all  packets  sent  by  host  158. 130.6. 140  to  TC  P 
port  5005  on  host  158.130.4.4." 

F  igure  3  shows  prototypes  for  the  principal 
functions  used  to  manage  framesets.  pigiet_ 
create_frameset  is  used  by  an  application  to 
create  a  frameset,  specifying  the  transmit  and 
receive  buffer  sizes  and  an  option  field  indicat¬ 
ing,  among  other  things,  which  services  should 
be  used  to  process  this  frameset.  O  nee  the  frame- 
set  has  been  created,  pigiet_set_fiiter  is 
called  to  associate  a  flow  specification  with  the 
frameset. 

A  n  example  of  a  service  provided  by  Piglet  is 
the  V  irtual  C  lock  algorithm,  a  mechanism  for 
scheduling  a  network  link  across  multiple  flows 
and  controlling  the  rate  at  which  each  flow 
sends  data.  V irtual  Clock  is  parameterized  by 
the  clock  period  and  maximum  amount  of  data 
to  be  sent  in  that  period;  tuning  these  two 
parameters  allows  an  application  to  specify  not 
only  its  bandwidth  requirement  but  also  the 
degree  of  burstiness  of  its  traffic.  The  function 
pigiet_set_vciock  is  used  to  convey  these 
parameters  to  Piglet. 


SQoSH  Resource  Multiplexing 
using  Piglet 

The  specific  problem  we  address  is  that  of  multi¬ 
plexing  a  single  network  interface  between  a 
number  of  uncooperative  applications,  each  of 
which  may  have  specific  requirements.  This  is 
exactly  the  challenge  faced  in  secure  multiplexing 
of  resources  once  a  policy  has  been  validated.  I  n 
this  example,  the  resource  we  wish  to  divide 
among  these  applications  is  network  bandwidth. 

The  Experimental  Description 

The  experimental  setup  for  this  test  consists  of 
two  PCs  connected  to  an  A santeF ast  100  M  b/s 
Ethernet  hub  by  3Com  3c905  network  interface 
cards.  The  sender  is  a  200  M  FI  z  dual-processor 
Pentium  Pro  PC  running  R ed H  at  Linux  5.0  with 
the  Piglet  kernel  replacing  the  standard  Linux 
kernel.  The  receiver  is  a  200  M  FI z  uniprocessor 
Pentium  Pro  PC  running  R ed H  at  Linux  4.2  with 
Linux  kernel  2.0.31.  Both  machines  are  idle 
apart  from  the  test  applications,  and  the  test  net¬ 
work  has  no  other  traffic. 

The  experiment  consists  of  three  applications 
all  trying  to  send  a  large  amount  of  data  from 
the  sender  to  the  receiver.  The  results  are  plot¬ 
ted  in  Fig,  4.  Each  application  has  different 
bandwidth  requirements: 

•  A  —  an  unconstrained  sender  that  uses  as 
much  bandwidth  as  is  available.  This  can  be 
viewed  as  the  source  of  a  D  oS  attack  in  the 
context  of  SQ oSH 

•  B  —  a  sender  constrained  to  run  at  40  M  b/s1 

•  C  —  a  sender  constrained  to  run  at  10  M  b/s 
The  application  used  to  send  the  data  is  the 

standard  ttep  augmented  with  an  option  to  set 
the  Virtual  Clock  parameters  (period  and  time). 
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These  parameters  are  passed  to  the  Linux 
TCP/IP  stack  by  setsockopt  ()  system  calls, 
where  they  are  then  passed  to  Piglet  to  create 
application-specific  framesets  with  those  param¬ 
eters.  This  is  the  only  modification  made  to  the 
Linux  networking  code. 

A  pplications  A,  B,  and  C  each  start  and  stop 
sending  their  data  at  different  times,  and  the 
per-application  bandwidth  is  measured  every 
second  and  plotted  in  F  ig.  2  as  the  three  heavy 
lines.  The  three  thinner  lines  show  reference 
bandwidth  measurements  for  each  sender  with 
no  competing  applications  over  a  30  s  period. 

•  After  1  s,  B  starts  sending  at  40  M  b/s.2 

•  After  5  s,  A  starts  sending  as  fast  as  possi¬ 
ble.  Piglet's  guarantee  of  40  M  b/s  to  B  lim¬ 
its  A  to  approximately  40  M  b/s  also. 

•  After  9  s,  C  starts  sending  at  10  M  b/s,  caus¬ 
ing  A's  bandwidth  to  decrease  by  approxi¬ 
mately  10  M  b/s. 

•  After  =15  s,  B  stops  sending;  A's  bandwidth 
thus  increases  to  approximately  10  M  b/s 
below  the  absolute  limit. 

•  After  =20  s,  A  stops  sending. 

•  After  =29  s,  C  stops  sending. 

Experimental  Results 

We  see  from  Fig.  2  that  Piglet's  queue  schedul¬ 
ing  mechanism  provides  controlled  multiplexing 
of  the  shared  network  resource,  despite  the  fact 
that  the  applications  are  not  cooperating  to 
share  the  resource;  neither  they  nor  the  host 
O.S.  (Linux)  are  aware  of  the  constraints 
imposed  on  them. 

The  applications  which  have  specific  band¬ 
width  requirements  receive  exactly  that  amount 
of  bandwidth,  even  when  an  application  with  no 
specified  constraint  is  competing  for  the  same 
resource.  This  ability  to  add  resource  manage¬ 
ment  to  a  standard  host  operating  system  is  one 
of  the  key  strengths  of  Piglet,  and  enables  its 
easy  integration  into  SQ  oSH  . 

Related  Work 

QoS  Provision  and  Management 

QoS  provision  and  management  has  a  wide-rang¬ 
ing  literature.  A  lot  of  the  early  work  was  stimu¬ 
lated  by  the  promise  of  asynchronous  transfer 
mode  (ATM  )  networks,  The  demand  for  these 
services  was  stimulated  by  multimedia  traffic. 
The  relevant  promise  was  the  control  of  multi¬ 
plexing  behavior  in  both  endpoints  and  network 
elements,  with  the  idea  that  ATM  hardware-sup¬ 
ported  queuing  disciplines,  such  as  Fair  Queuing 
or  its  many  variants,  could  be  used  to  allocate 
bandwidth  resources,  and  for  the  most  part  pro¬ 
vide  delay  bounds.  While  such  hardware  support 
remains  attractive,  the  signaling  software  has 
proved  sufficiently  unwieldy  that  the  potential  for 
managed  bandwidth  remains  largely  unrealized. 

The  attraction  of  integrated  services  did 
serve,  however,  to  revitalize  and  stimulate 
research  into  integrated  services  in  the  IP  Inter¬ 
net  community.  This  research  program  resulted 
in  the  RSVP  proposal  for  signaling  resource 
reservations  to  network  elements  by  endpoints, 

N either  ATM  signaling  protocols  nor  R SV  P 
provide  the  integrated  admission  control  and 
policing  of  SQ  oSH  .  It  is  presumed  that  adminis¬ 


trative  entities  are  trusted  in  either  system,  while 
policing  is  delegated;  to  hardware  in  the  ATM 
setting,  and  to  some  lower  layer  through  the 
I  nternet  subnet-specific  layer  in  the  RSV  P  case. 

Some  extensions  for  securing  signaling  are  dis¬ 
cussed  bySchuba  [9],  An  additional  limitation  of 
these  systems  is  that  their  policing  is  limited  to 
bandwidth  management. 

Secure  Resource  Control  in 
Active  and  Programmable  Networks 

SA  N  E  has  no  direct  analogs  in  ongoing  work  on 
active  networks  [10],  W  hile  A  NTS  uses  M  D  5 
hashes  ("fingerprints")  to  name  on-demand 
loaded  modules,  the  hashes  provide  unique 
names  rather  than  security.  The  ANTS  execution 
environment  depends  on  the  J  ava  programming 
language  for  protection,  a  dependency  shared  by 
many  active  network  prototypes.  U  nfortunately, 
as  W all ach  etal.  [11]  note,  J  ava's  security  is  sus¬ 
pect.  The  remote  authentication  and  namespace 
security  aspects  of  SA  N  E  address  issues  ignored 
in  these  systems,  and  could  be  applied  even  in 
cases  where  J  ava  is  used  (e.g.,  to  provide  integri¬ 
ty  checking  of  the  J  V  M  or  layers  beneath  it,  as 
well  as  on-demand  loaded  modules). 

PLAN  [12]  is  a  part  of  the  S witch W are  pro¬ 
ject  at  the  U  niversity  of  Pennsylvania.  The  PLAN 
project  is  investigating  the  trade-offs  brought 
about  by  using  a  different  language  for  active 
packets  than  is  used  for  active  extensions,  PLAN 
is  designed  so  that  pure  PLAN  programs  will  not 
be  able  to  violate  the  security  policy.  Because 
this  limits  the  operations  that  can  be  performed, 

PLAN  programs  can  call  services  which  can  be 
either  active  extensions  or  facilities  built  into  the 
system,  perhaps  requiring  authentication  and 
authorization  before  allowing  access  to  the 
resources  they  protect. 

The  Safetynet  Project  [13]  at  the  U  niversity  of 
Sussex  has  also  designed  a  new  language  for  active 
networking.  They  have  explicitly  enumerated  what 
they  feel  are  the  important  requirements  for  an 

active  networking  language  and  then  set  about  2  ttcp  actually  tries  to  send 

designing  a  language  to  meet  those  requirements.  as  fast  as  possible,  but 
I  n  particular,  they  differ  from  PLAN  in  that  they  Piglet  constrains  packet 

hope  to  use  the  type  system  to  allow  safe  accu-  transmission  to 40 Mb/s. 
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mulation  of  state.  They  appear  to  be  trying  to 
avoid  having  any  service  layer  at  all, 

An  architecture  which  extended  a  protection 
model  from  the  local  domain  to  a  distributed 
environment  was  provided  by  Sansom  etal.  [14], 
where  protection  was  enforced  locally  with  mem¬ 
ory-protection  enforced  capabilities.  The  capa¬ 
bilities  were  extended  to  remote  nodes  via 
cryptographic  means.  SA  N  E  provides  more  gen¬ 
eral  mechanisms  and  could  thus  be  specialized 
to  such  an  application  (moving  memory-protect¬ 
ed  objects  about  the  network)  but  more  impor¬ 
tantly  guarantees  local  integrity  before  extending 
itself  into  the  network. 

Security  of  active  networks  is  a  broad  evolv¬ 
ing  area.  We  suggest  M  oore  [15]  as  a  source  of 
additional  information  in  this  area. 

SQoSH  and  Other  Environments 

The  Cambridge  U  niversity  Nemesis  operating  sys¬ 
tem  has  considerable  potential  for  supporting 
SQoSH  functionality  since  its  single-layer  multi¬ 
plexing  model  can  readily  be  adapted  to  the 
SQoSH  policing  requirements.  The  RCA NE  sys¬ 
tem  [16]  follows  the  A  LI  E  N  architecture  but  uti¬ 
lizes  the  capabilities  of  Nemesis  to  provide  resource 
management  and  control  in  a  manner  equivalent 
to  Piglet's  role  in  the  SQoSH  architecture. 

A  nother  system  with  great  potential  is  the 
A  rizona  Scout/E  scort  operating  system  with  its 
support  for  end-to-end  resource  allocations, 
called  paths.  Paths,  in  spirit,  are  the  right  idea 
for  end-to-end  allocation  in  an  active  network. 
The  security  infrastructure  is  not  as  complete  as 
SA  N  E  ,  with  its  secure  initialization,  public-key 
infrastructure,  A  LI  E  N  active  loader,  and  remote 
module  authorization  certificates.  We  believe 
that,  like  Nemesis,  Scout  could  readily  be  adapt¬ 
ed  to  support  SQoSH . 

Conclusions  and  Future  Work 

The  SQ  oSH  architecture  provides  controlled 
access  to  allocations  of  system  resources  in  an 
active  network  element.  It  is  more  generally 
applicable  to  any  resource  allocation  or  policing 
scheme  where  remote  allocation  and  dealloca¬ 
tion  of  resources  are  required.  W e  believe  that 
this  new  architecture  is  well  suited  to  providing 
secured  resource  allocation  in  an  integrated  ser¬ 
vices  internetwork. 

A  n  example  of  the  general  architecture  can 
be  constructed  using  SA  N  E  as  a  protective 
mechanism  for  resource  allocations  available 
from  the  Piglet  operating  system.  We  have 
demonstrated  Piglet  partitioning  bandwidth 
using  a  V  irtual-C lock-like  queue  scheduling  dis¬ 
cipline.  The  measurements  showed  the  effective¬ 
ness  of  Piglet  on  this  task. 

Since  SA  N  E  operations  are  in  the  SQ  oSH 
"control  plane,"  they  are  performed  infrequently 
relative  to  the  policing  functions;  thus,  the  cost  of 
its  cryptographic  mechanisms  has  a  minor  effect 
on  overall  performance.  An  additional  benefit  of 
SA  N  E 's  use  of  a  public-key  infrastructure  is  the 
presence  of  this  infrastructure  for  preserving  pri¬ 
vacy  and  integrity  of  media  streams  if  required. 

We  believe  that  SQoSH  represents  a  practical 
advance  in  automating  and  securing  the  adminis¬ 
tration  of  remote  network  elements  of  any  type. 


W  e  present  the  threat  model  SQ  oSH  addresses, 
and  show  that  these  attacks  can  be  thwarted. 
Typical  architectures  and  implementations  pro¬ 
vide  no  protection  against  such  attacks,  except 
perhaps  via  inflexibility.  In  any  environment 
where  resources  and  resource  allocations  have 
value,  SQoSH  ensures  that  the  resources  are 
allocated  as  intended. 
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